ProtoLeaks: A Reliable and Protocol-Independent Network Covert Channel

Abstract. We propose a theoretical framework for a network covert channel based on enumerative combinatorics. It offers protocol independence and avoids detection by using a mimicry defense. Using a network monitoring phase, traffic is analyzed to detect which application-layer protocols are allowed through the firewalls. Using these results, a covert channel is built based on permutations of benign network objects, such as FTP commands and HTTP requests to different web servers. Any protocol that offers reliability guarantees can be plugged into the framework. This includes any protocol that is built on top of the TCP protocol. The framework closely mimics the behavioral statistics of the legitimate traffic, making the covert channel very hard to detect

LibSEAL: revealing service integrity violations using trusted execution

Users of online services such as messaging, code hosting and collaborative document editing expect the services to uphold the integrity of their data. Despite providers’ best efforts, data corruption still occurs, but at present service integrity violations are excluded from SLAs. For providers to include such violations as part of SLAs, the competing requirements of clients and providers must be satisfied. Clients need the ability to independently identify and prove service integrity violations to claim compensation. At the same time, providers must be able to refute spurious claims. We describe LibSEAL, a SEcure Audit Library for Internet services that creates a non-repudiable audit log of service operations and checks invariants to discover violations of service integrity. LibSEAL is a drop-in replacement for TLS libraries used by services, and thus observes and logs all service requests and responses. It runs inside a trusted execution environment, such as Intel SGX, to protect the integrity of the audit log. Logs are stored using an embedded relational database, permitting service invariant violations to be discovered using simple SQL queries. We evaluate LibSEAL with three popular online services (Git, ownCloud and Dropbox) and demonstrate that it is effective in discovering integrity violations, while reducing throughput by at most 14%

Teechain: a secure payment network with asynchronous blockchain access

Blockchains such as Bitcoin and Ethereum execute payment transactions securely, but their performance is limited by the need for global consensus. Payment networks overcome this limitation through off-chain transactions. Instead of writing to the blockchain for each transaction, they only settle the final payment balances with the underlying blockchain. When executing off-chain transactions in current payment networks, parties must access the blockchain within bounded time to detect misbehaving parties that deviate from the protocol. This opens a window for attacks in which a malicious party can steal funds by deliberately delaying other parties' blockchain access and prevents parties from using payment networks when disconnected from the blockchain. We present Teechain, the first layer-two payment network that executes off-chain transactions asynchronously with respect to the underlying blockchain. To prevent parties from misbehaving, Teechain uses treasuries, protected by hardware trusted execution environments (TEEs), to establish off-chain payment channels between parties. Treasuries maintain collateral funds and can exchange transactions efficiently and securely, without interacting with the underlying blockchain. To mitigate against treasury failures and to avoid having to trust all TEEs, Teechain replicates the state of treasuries using committee chains, a new variant of chain replication with threshold secret sharing. Teechain achieves at least a 33X higher transaction throughput than the state-of-the-art Lightning payment network. A 30-machine Teechain deployment can handle over 1 million Bitcoin transactions per second

Security Primitives for Protected-Module Architectures Based on Program-Counter-Based Memory Access Control

Our society increasingly depends on computing devices. Customers rely on laptops and mobile devices to access security sensitive applications such as online banking. Companies have to protect their trade secrets. And governments have to guard their country's critical infrastructure against espionage and sabotage. Security of computing devices in such use cases is paramount and various security measures have been developed that raise the bar significantly for attackers. However, vulnerabilities in such systems still exist and are frequently exploited successfully. A common pitfall is that software security takes a layered approach where privileged layers keep getting extended with new components over the system's lifetime. This results in a snowball effect on the size of these privileged levels and this in turn increases the likelihood of software vulnerabilities. As all applications running on the device rely on the integrity of these layers, increasing the size of their code base has a negative impact on security of the overall device.Many security measures have been proposed to automatically harden the most privileged software layer, but they all fail to provide strong security guarantees. In this thesis, we considered a different approach. We developed three security primitives that can be applied at most privilege levels. Unlike related approaches, this set of primitives is fixed. Software components can be added easily at any privilege level, but no additional primitives will be required. Moreover, these security primitives can provide provable security guarantees.The most important security primitive is a program-counter-based access control mechanism. By enforcing different access rights on physical memory depending in which code module the processor is executing, sensitive parts of an application can be strongly isolated. For instance, a cryptographic key can be isolated to a protected module implementing a certificate-signing service.Since the key cannot be accessed by any other code than the module's, it cannot be stolen even if malware was already present on the platform. The access control mechanism also guarantees that the module is only accessible through the interface that it exposes explicitly.Second, we enable protected modules to limit which protected modules can access their services. Unrestricted access to modules may still allow a large range of attacks. While an attacker may no longer be able to access a well-isolated cryptographic key, for example, the exposed interface may still allow her to sign forged certificates. We prevent such attacks using a capability-based access control mechanism; a module can only be accessed if the caller ever received the capability to do so.Third, we propose a fast and practical state-continuity system. Using cryptographic properties, protected modules can use many services of the unprotected, legacy system while providing strong security guarantees. Unfortunately, these security guarantees only are ensured while the system is up and running. In practice systems crash, loose power or need to reboot. Integrity and confidentiality protecting the module's state before it is stored on disk is insufficient in such cases. Care must be taken that an attacker cannot present a stale state of a protected module as being fresh. Practical implementations are hindered by the substantial economical costs to add non-volatile storage to the processor. Many computing devices are already shipped with access-controlled non-volatile storage off-chip, but this memory is slow, very limited in size and wears out quickly. We propose an algorithm based on a simple hardware component to avoid all these shortcomings.During this dissertation we also focused on how these newly-added security primitives can be applied to provide strong security guarantees. A fully-abstract compilation scheme was developed that ensures that software-level abstractions provided to programmers cannot be broken; for every low-level attack, there also exists an attack at source-code level. This significantly simplifies reasoning about the security guarantees that protected modules provide and increases security of the overall system.status: publishe

Fides: Selectively hardening software application components against kernel-level or process-level malware

Protecting commodity operating systems against software exploits is known to be challenging, because of their sheer size. The same goes for key software applications such as web browsers or mail clients. As a consequence, a ignificant fraction of internet-connected computers is infected with malware. To mitigate this threat, we propose a combined approach of (1) a run-time security architecture that can efficiently protect fine-grained software modules executing on a standard operating system, and (2) a compiler that compiles standard C source code modules to such protected binary modules. The offered security guarantees are significant: relying on a TCB of only a few thousand lines of code, we show that the power of arbitrary kernel-level or process-level malware is reduced to interacting with the module through the module's public API. With a proper API design and implementation, modules are fully protected. The run-time architecture can be loaded on demand and only incurs performance overhead when it is loaded. Benchmarks show that, once loaded, it incurs a 3.22% system-wide performance cost. For applications that make intensive use of protected modules, and hence benefit most of the security guarantees provided, the performance cost is up to 14%.status: publishe

Ariadne: A minimal approach to state continuity

Protected-module architectures such as Intel SGX provide strong isolation guarantees to sensitive parts of applications while the system is up and running. Unfortunately systems in practice crash, go down for reboots or lose power at unexpected moments in time. To deal with such events, additional security measures need to be taken to guarantee that stateful modules will either recover their state from the last stored state, or fail-stop on detection of tampering with that state. More specifically, protected-module architectures need to provide a security primitive that guarantees that (1) attackers cannot present a stale state as being fresh (i.e. rollback protection), (2) once a module accepted a specific input, it will continue execution on that input or never advance, and (3) an unexpected loss of power must never leave the system in a state from which it can never resume execution (i.e. liveness guarantee). We propose Ariadne, a solution to the state-continuity problem that achieves the theoretical lower limit of requiring only a single bit flip of on-volatile memory per state update. Ariadne can be easily adapted to the platform at hand. In low-end devices where non-volatile memory may wear out quickly and the bill of materials (BOM) needs to be minimized, Ariadne can take optimal use of non-volatile memory. On SGX-enabled processors, Ariadne can be readily deployed to protect stateful modules (e.g., as used by Haven and VC^3).status: publishe

Developing secure SGX enclaves: New challenges on the horizon

The combination of (1) hard to eradicate low-level vulnerabilities, (2) a large trusted computing base written in a memory-unsafe language and (3) a desperate need to provide strong software security guarantees, led to the development of protected-module architectures. Such architectures provide strong isolation of protected modules: Security of code and data depends only on a module's own implementation. In this paper we discuss how such protected modules should be written. From an academic perspective it is clear that the future lies with memory-safe languages. Unfortunately, from a business and management perspective, that is a risky path and will remain so in the near future. The use of well-known but memory-unsafe languages such as C and C++ seem inevitable. We argue that the academic world should take another look at the automatic hardening of software written in such languages to mitigate low-level security vulnerabilities. This is a well-studied topic for full applications, but protected-module architectures introduce a new, and much more challenging environment. Porting existing security measures to a protected-module setting without a thorough security analysis may even harm security of the protected modules they try to protect.status: publishe